はじめに

こんにちは、かみとです。

re:Inventのセッションレポートです。

このセッションは、前半にトレンドマイクロ社の副社長でありプロダクトマネージャーのEric Shulze氏を迎えて、トレンドマイクロ社で採用しているAWS IoTを用いたクラウドネイティブなネットワーク・インフラのデザインパターンについて踏み込んだ内容と、後半はAWS IoT ゼネラルマネージャーのShyam KrishnamoorthyによるAWS IoTの真の目的といえる、エッジ・トゥ・エッジに至るまでお客様のが引き起こすイノベーションをサポートするためのテクノロジーについてのお話でした。

前半のセッションは、前回の『【レポート】Unlocking innovation: Differentiate your product with new IoT features #IOT201』で紹介のあったトレンドマイクロ社のIoT Core活用事例について、もっと踏み込んだ内容が聞けるとのことで楽しみにしていました。

このセッションレポートでは、前半の部分にフォーカスしたまとめとなっています。

Design patterns for distributed client server systems via IoT (sponsored by Trend Micro)

What is the cloud-native version of TCP/IP communication? Computing, storage, and databases have common cloud-native solutions, but a majority of networking operations are still using legacy solutions. Despite advancements in automation, many networking developers still have to manually consider which port to use and manage certificate management and server/client identities. In this session, learn how Trend Micro adopted AWS IoT as the networking version of cloud native, where AWS handles the undifferentiated heavy lifting and scales operations, connection management, and device identity. This presentation is brought to you by Trend Micro, an AWS Partner.

クラウドネイティブ版TCP/IP通信とは？コンピューティング、ストレージ、データベースには一般的なクラウドネイティブソリューションがありますが、ネットワーク運用の大部分にはまだレガシーソリューションが使用されています。自動化が進んでいるとはいえ、多くのネットワーク開発者は、どのポートを使用するかを手動で検討し、証明書管理やサーバ/クライアントのID管理を行う必要があります。本セッションでは、トレンドマイクロがAWS IoTをネットワーク版クラウドネイティブとして採用し、AWSが未分化な力仕事を処理し、運用、接続管理、デバイスIDをスケールアップした方法を紹介します。本講演は、AWSパートナーであるトレンドマイクロの提供によるものです。

• Speakers:
  • Shyam Krishnamoorthy, General Manager, AWS IoT, Consumer IoT and Connectivity, Amazon.com
  • Eric Shulze, Vice President, Product Management, Trend Micro
• Session type:
  • Breakout Session
• Session level:
  • 300 - Advance

IoTによる分散型クライアントサーバーシステムのデザインパターンについて

• IoTは、クライアント・サーバ・ネットワーキングを基本的に置き換えるために、どのように役立っているか、どのような制限を克服したか、など。

私たちが会社として解決したかった問題

• クライアント・サーバー・コミュニケーションのために、スケーラブルなクラウド・ネットワーキングにする必要があったが、プロビジョニング認証のオーバーヘッドがあった
  • これらのインフラは製品が正しく機能するために必要ではあるが、しかしこれは顧客に直接的な価値を提供するものではない。
• EDR（エンドポイント・ディテクション・アンド・レスポンス）
  • ノートパソコンやサーバー内の、ファイルのオープン、権限、ネットワーク接続などを記録・監視している
  • トラブルについて対策を講じるためにリモートシェルを実行できるようにする必要があり、迅速な双方向通信が必要となる
• スケーラビリティと管理性
  • １億人のエージェントに対応できるかを目標にした
  • まだそこまでのエージェント数ではないが、長期的な目標として設定した
  • ロードバランサーとELBとEC2ではコストに大きく影響することがわかっていたため、この問題を解決する方法を見つける必要があった
• 世界中に多くのエージェント
  • エージェントと現在の顧客基盤を移行期間中に簡単に統合する必要があった
• ビジネスをより早く実行できるようにしなければならない
  • 新しい機能にはいち早く適応しなければならない
  • モジュール化を推進
  • トレンドマイクロ社内の他のチームが追加機能をしても、サーバーやクラウド通信ネットワークの再試行を心配する必要がないようにする
  • 平均して1日あたり25～30メガバイトのデータがエンドポイントに送信される
    • 接続時間が長くなるほど、コネクションを維持するコストがかかるためサーバーが処理できる数も少なくなり、スケールが低下していく
• こういった問題点から、クラウドネイティブに移行することによりリニアな成長を遂げてきた

現在の状況

• 私達がSaaSハイブリッドと呼ぶAWSのアーキテクチャにより、完全にAWSで実行される
  • IoT Coreを導入して、イベントデータをフィードバックするようにした。つまり、イベントストリーム、イベントデータストリームなどを取り込んだ
  • 現在では、主にアップロードチャネルを扱っている。
  • エンドポイントからクラウドに送られるデータは、すべてこのチャンネルを経由する。
• エンドポイントで新しいファイルが作成され、ネットワークに接続されると、すべてのテレメトリーデータ(アプリケーションがパフォーマンス改善や品質向上のために収集するユーザーの利用状況データ)がパッケージングされ、AWSに戻される。
  • IoTルールエンジンを使って、そのデータを適切な宛先に書き出す。

このアーキテクチャから得られた成果

• 最初の大きな収穫は、既存のエージェントが安定して働き続けていること
• 新しいEC2プールの作成が不要となった
  • 既存のチャネルを使って新しいIoTを設定し、エージェントのアップグレードを行い、IoTコンポーネントの信頼性、アイデンティティを確立して、クラウドにプッシュする。
• 複数対１のデータ転送パターンも可能となる
  • モノリス・アプリケーション上で接続が開かれるのを待つ必要がない
  • すべてのエージェントが同時にクラウドに送信することができる
  • IoTは、これらの受信接続をすべて処理し、同時にバックエンドの処理に転送できるように拡張することが可能
• しかしこのアーキテクチャは完璧ではない
  • まだまだたくさんのEC2を管理する必要がある
  • 現在でも、全世界で70台以上のEC2を管理している
  • ローリングアップグレードを行うたびに、すべてのエンドポイントやサーバーのアップグレードが必要となり、コストや運用の観点からは、最も安価に運用できるわけではない
  • モデルは小さくなったので大きな機能追加は必要ではなくなったものの、データベースへのアクセスなどまだ多くの依存関係がある。
  • 大いに役立っているが、すべてのプレッシャーから開放されたわけではない

今後目指す先は

• すべてがIoTを経由するようにしたい
• ルールエンジンがAWSの適切なバックエンドのマイクロサービスにデータをルーティングし、AWSで実行されるトレンドマイクロ社のサービスを実行できるようにしたい

• EC2が完全になくなった状態にたどり着きたい
  • EC2 fleetを運用する必要もなければ、インスタンス容量を気にする必要もない
• エージェントに必要なFQDNを減らすことができる
  • なぜなら現在多くのお客様が、特にクラウド基盤のサーバーにおいて、アウトバウンド接続を制限し、すべてのアウトバウンド接続をホワイトリスト化することを望んでいる
  • 例えばいきなりFQDNのプールが70個もある場合、お客様にとって、1つか2つか3つで済むところを70ものURLをホワイトリストに登録するようセキュリティチームに依頼するのは、楽しい会話ではないので、他のチームとやり取りをして技術を環境に導入する際の摩擦をなくすことができます。
• IoTエンジン経由でトラフィックをルーティングすることで、モノリスをどんどん分解している
  • モデルからデータを切り離すのではなく、ルールエンジンの時点でデータを切り離すことができる
  • そうすることで依存関係が解消され、データベース依存の問題も細分化されて小さくなり、クリティカルな問題ではなくなってくる
• エージェントジョブは、エージェント接続に依存しなくなった。
  • なぜなら、エージェントはこのコマンドを取得するために実際のアプリケーション層と会話する必要がないから
  • IoT経由やメッセージバスでステージングすることができる
  • つまり、このモデルでは、もうアプリケーションがすべてのジョブを処理するのを待つ必要はない
• 認証は、我々のアプリケーションの外で行われるため、もう認証を処理する必要はない
  • アクティベーションの一部を処理する必要はあるが、エージェントとクラウドの間の認証は、AWS IoTがすべて処理してくれる
  • 認証は製品のために必要な要件（あたりまえ品質）ではあるが、差別化の要因にはならず、お客様が製品に支払う価値ではない
• 様々なデータパターンをサポートしている
  • 1対1のエンドポイントにジョブを送る必要がある場合はもちろん、複数のエンドポイントに対しても１つのジョブとして送信することができる
  • セキュリティにおいて、インシデント・レスポンス時にいかに早くエンドポイントに情報を届けるか、またはブロックリストを出すかが重要なポイント

私たちが扱う課題

• エージェントの再活性化とクローン
  • IoTデバイスならシリアルナンバーなどがハードコーディングされているが、エージェントの場合はエージェントIDをどのように効率的に再投入したり新しいIDを作成したりするとよいか
  • よくある方法として一般的なクローン作成なども効果的に使える
• オフラインのエージェント、メッセージ、キュー、リトライ
  • 大量のデータを押し流す際、どうすればデータが失われることがないかを確認する必要がある
  • セキュリティ面ではログが失われることは許されない
  • そこで、AWSがすでに提供している方法に加えて、内部でそれをキューに入れる方法を検討する必要がある
  • オフラインも考慮する必要がある。どのようにキューイングすれば、接続されたときにできるだけ効率よく送信できるようになるか
• 大容量のファイル転送
  • MQTTはプロトコルの一部としてサイズ制限があるのは素晴らしい点だが、私たちのユースケースではエンドポイントからファイルを収集するような場合、たとえばマルウェアのファイルなどのケースだと128キロバイト未満であることはほとんどない
  • ではどのようにそのファイルを転送するか
    • 私たちはファイルを分割して個別のMQTTメッセージとして送信する技術を持っている
    • これをクラウド上で再結合し、ハッシュで検証した後にS3バケットにドロップする
    • ファイルをそのままS3バケットにアップロードする方法も検討したが、FTTNがもっと必要となり、お客様のプロセスの他の部分に摩擦を生じるようになった

なぜIoTなのか？

• エージェントサーバのスケーリング、リトライ、接続、セキュリティ、その他をすべてAWSがハンドリングしてくれる
  • デバイスをIoT Coreにアクティベートするだけで、その他の接続はすべてAWSが行ってくれる
• ネットワークについて心配する必要がなくなったので、社内のチームの業務がより早くなった
  • 新しいチームがエージェントに新しい機能を追加して、お客様にもっと価値を提供したいと考えた場合、IoTバスにトピックを追加し、エージェントはSDKでクラウドにデータを送信することで実現が可能
  • 新たなサーバーエージェントの通信を再構築する必要がなく、車輪の再発明が不要
• 複数のエージェントにより効率的に伝えることができる
  • システムの負荷を軽減し、エージェントへのタスクの伝達をより迅速に行うことができるようになった
  • タスクを複数のエージェントにディスパッチすることができる。つまり、30第のエンドポイントにジョブを送信したいと思ったときに、システム内の１つのタスクで同時にそれを行うことができる
  • また、重要なのは複数のエージェントが一度にデータ送信することが可能だということ
    • モノリスへの接続を気にする必要がない
    • IoTに一度に複数の接続が来て、それをルールで横にルーティングすることができる
• データを必要な場所にルーティングするようなルールがある
  • Rules Engineはルーティングロジックをアプリケーションから完全に排除することができる
  • モノリスやデータベースから他のパーツに問い合わせる必要がなくなった

さらにその先に

• AWS IoT Greengrass
  • エージェントにより近いところで処理を行うことができる
  • 社内でGreengrassを使ったいろいろなユースケースが発見されている
  • エージェントがクラウドのIoTと直接話すのではなくGreengrassを介すことで、アウトバウンドの接続も制限することができる
• AWS IoTを、エージェントのユースケース以外の活用方法について
  • 従来のサーバ・クライアント・アーキテクチャのモデルに対して、ネットワーク・アプライアンスを管理するために使用することが可能かもしれない
  • VicOne（トレンドマイクロ社が展開するコネクテッドカーのセキュリティ製品）への展開の可能性もある

まとめ

IoTの枠にとらわれないAWS IoTのサービスの活用方法としてとても参考になりました。

IoTという名前のサービスというだけにどうしてもIoTデバイスと接続することを前提としてしまいがちかと思いますが、フルマネージドサービスとしてAWS IoTを見たときに、マッチするユースケースは思っている以上にいろいろあるのかもしれません。